Lock reservation is a technique used by run-time systems (e.g., a Java virtual machine) to reduce the overhead associated with thread object access synchronization (also referred to as locking). (Java is a trademark of Oracle Corp.) Lock reservation assumes that most locks do not actually participate in inter-thread activities and can thus be ignored. One example of a prior art lock reservation technique is disclosed in U.S. Patent Application Publication No. US2005/0289549A1, entitled “Lock Reservation Methods and Apparatus for Multi-Threaded Environments” by Cierniak et al, which published on Dec. 29, 2005, and is incorporated by reference herein.
Lock reservation is extremely effective for applications which have little or no actual thread interaction (i.e., referred to hereafter as “lock contention”). Lock reservation, however, may introduce significant additional performance overhead if reservation is used in cases where contention does occur. Therefore, it is very important to select appropriate situations in which to apply lock reservation, which also means that lock reservation may not be applicable in all cases.
Several solutions have been used or proposed to enhance the effectiveness of lock reservation. First, lock reservation may be enabled globally through the use of a command line option or other configuration flag. This solution places the onus of the decision upon the end user and is therefore undesirable. Second, lock reservation may be enabled for objects, which are instances of particular classes. This requires an effective heuristic for choosing such classes and assumes that instances of the class have similar locking characteristics.
Third, lock reservation may be adaptively enabled for objects or classes of objects within the system. This requires that statistics be gathered during the execution and incurs a certain start up cost as the runtime system learns the characteristics of the application. It also assumes that an object's locking characteristics do not change throughout its lifetime. Fourth, the objects reserved by one thread are reassigned to be owned by a new thread that is locking an object, using bulk object re-biasing. Such a technique, however, assumes that the threads use the objects in certain manner, that is, all objects reserved by one thread will be handed over to another thread. In general, applications may not behave this way and bulk re-biasing will happen all the time, impeding application performance.
Lock coarsening is a technique which is used by compilers (especially Java just-in-time compilers) to combine adjacent mutual exclusion regions (lock regions), usually performing thread synchronization on the same object. Lock coarsening reduces the number of locking operations which must be performed by identifying and removing redundant lock operations. The lock removal is based on static compiler analysis, where the lock region is extended replacing shorter adjacent locked regions. This way the number of lock and unlock operations is reduced, leading to better performance.
Lock coarsening, however, has a limited scope of applicability. There are a number of restrictions that are imposed on the lock optimization procedure, such as not being able to coarsen across other locks. For example, coarsening across region of code that locks another object may result in a deadlock situation where one didn't exist before. This restriction makes it difficult to apply lock coarsening across calls and potential exception points.